home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 36 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: news.mindlink.net!news
  2. From: genew@mindlink.bc.ca (Gene Wirchenko)
  3. Newsgroups: comp.lang.c,comp.lang.c++
  4. Subject: Re: Poor floating point code in BC++
  5. Date: Tue, 02 Jan 1996 02:25:55 GMT
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <4ca5bk$ff@fountain.mindlink.net>
  8. References: <4c9sja$gke$1@mhafc.production.compuserve.com>
  9. NNTP-Posting-Host: line028.nwm.mindlink.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. Dave Hand <70621.3624@CompuServe.COM> wrote:
  13.  
  14. >BC++ 4.51 seems to generate very poor floating point code. I would be
  15. >interested to know how well other compilers do on the following
  16. >examples. These were compiled using options: i486 CPU, fast floating
  17. >point, optimize for speed, large memory model.
  18.  
  19. >main()
  20. >    {
  21. >    double x,y,z;
  22. >    int n;
  23.  
  24. >    x = 4.5;
  25. >    y = 10.7;
  26. >    n = x;
  27. >    z = x * y;
  28. >    }
  29.  
  30. >Plain arithmetic, such as z = x * y, is generated inline as one would
  31. >expect. You would think the line n = x would be quite fast. However,
  32. >it generates a function call:
  33.  
  34. >n=x;
  35. >    wait
  36. >    fld qword ptr[bp-0A]
  37. >    call far FTOL@
  38. >    mov [bp-02],ax
  39.  
  40. >where FTOL@ is a very long function for what is does:
  41.  
  42. >    push bp
  43. >    mov bp,sp
  44. >    sub sp,000A
  45. >    fnstcw word ptr[bp-02]
  46. >    fwait
  47. >    mov al,[bp-01]
  48. >    or byte ptr[bp-01],0C
  49. >    fldcw word ptr[bp-02]
  50. >    fistp qword ptr [bp-0A]  <<-- here is the meat of it.
  51. >    mov [bp-01],al
  52. >    fldcw word ptr[bp-02]
  53. >    mov ax,[bp-0A]
  54. >    mov dx,[bp-08]
  55. >    mov sp,bp
  56. >    pop bp
  57. >    retf
  58.  
  59. >I was trying to optimize some graphics code. The net result is that
  60. >in many graphics calculations, the final conversion from world
  61. >coordinates to screen coordinates is the overwhelming majority of the
  62. >time. There are many other places where BC++ seems to generate very
  63. >bad floating point code (unless I'm missing some important point). I
  64. >would very much like to know if other compilers do a better job (or
  65. >set me straight as to why the above code makes sense).   
  66.  
  67.      That there is a function call is no surprise.  X is float and n
  68. is int.  A conversion is necessary.  From the name, that looks like
  69. what the routine called does.
  70.  
  71. Sincerely,
  72.  
  73. Gene Wirchenko
  74.  
  75. C Pronunciation Guide:
  76.      y=x++;     "wye equals ex plus plus semicolon"
  77.      x=x++;     "ex equals ex doublecross semicolon"
  78.  
  79.